Electronic circuits and systems often communicate with each other via a communication link referred to as a “bus.” A variety of bus architectures are well known. Simple buses uses as few as two active wires, although they may include additional wires for other functions. For example, an inter-integrated circuit (I2C) bus consists of two communication wires, a serial data line (SDA) and a serial clock line (SCL).
I2C buses are used to provide communications between two integrated circuits (ICs), for example, two or more ICs on a printed circuit board (PCB) or ICs on different PCBs. The I2C bus also may be used as a network link between electronic systems, for example in automation or control system applications. Architectures like the I2C bus are relatively easy to implement, however, there are problems. One common problem relates to situations in which one of the active lines of the bus becomes hung-up or stuck in a particular state that prevents further use of the bus.
An example of an I2C bus providing communications between an intelligent control device and one or more general purpose application oriented circuits may help to demonstrate the problem. In most such cases the intelligent control device is a microcontroller unit (or MCU), and the general purpose circuits are slave devices. Some examples of slave devices are temperature sensors, memories, system monitors and LED drivers. The I2C bus protocol involves bidirectional communication between the devices communicating. In a typical example, the MCU asserts the I2C bus, addresses the slave device and requests to make a read from its internal register. The slave device asserts the I2C bus with an acknowledge signal, and then proceeds to put data from its register on the I2C bus. The MCU clocks the slave device, to receive the data. The slave device puts a bit of data on the bus per clock pulse that it receives from the MCU.
A problem occurs when the slave becomes out of sync with the master device, the MCU in the example. The slave device with data to send is waiting for another clock pulse, but the MCU thinks it has already sent out enough clock pulses. In the I2C protocol, a device asserts the bus by pulling the data line low. Hence, in this example, if the out-of-sync slave device is holding the data line low, all further communications are prevented, because that line is low and can not be cleared by the device until it receives another clock pulse (which the MCU does not intend to send). The I2C bus therefore is stuck.
Current systems must provide protection for this type of fault. Typically, systems must incorporate hardware and software to be able to identify, isolate and fix stuck I2C buses. Discrete hardware for these solutions requires valuable PCB space and may require dedicated connector pins. Under software control, the hardware must disconnect each card containing one or more slave devices, one at a time, until the fault clears, hence identifying the faulty card. Then, the software controls the hardware to reconnect to the faulty card only and send out clock pulses to clear the device that has been holding the bus low. If successfully received, these clock pulses allow the device to output its data. However, during this time, other devices remain disconnected and cannot use the bus.
Some systems, after identifying the bad card, require the card to be physically removed from the system and reinserted. Another solution is a system power cycle or analog switches to disconnect the power from specific circuits on the I2C bus. A power cycle will reset the device which is holding the bus low.
These methods are not very efficient. Pulling out cards or power cycling requires a significant amount of time and human involvement. Discrete hardware and software solutions using circuits to disconnect each card, one at a time to isolate a fault, require a significant amount of circuitry, PCB space and dedicated connector pins. Also, these solutions often require considerable time, during which the bus cannot even be used by other operative devices, while attempts are made to clear the device that caused the fault.
A need exists for a more effective technique to automatically isolate and resolve a stuck bus line. Any solution should require relatively simple circuitry and be relatively easy and cheap to manufacture, e.g. due to low component count.